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Abstract. Current garbage collectors leave a lot of garbage uncollected 
because they conservatively approximate liveness by reachability from 
program variables. In this paper, we describe a sequence of static analy- 
ses that takes as input a program written in a first-order, eager functional 
programming language, and finds at each program point the references 
to objects that are guaranteed not to be used in the future. Such refer- 
ences are made null by a transformation pass. If this makes the object 
unreachable, it can be collected by the garbage collector. This causes 
more garbage to be collected, resulting in fewer collections. Additionally, 
for those garbage collectors which scavenge live objects, it makes each 
collection faster. 

The interesting aspects of our method are both in the identification of the 
analyses required to solve the problem and the way they are carried out. 
We identify three different analyses — liveness, sharing and accessibility. 
In liveness and sharing analyses, the function definitions are analyzed 
independently of the calling context. This is achieved by using a variable 
to represent the unknown context of the function being analyzed and 
setting up constraints expressing the effect of the function with respect 
to the variable. The solution of the constraints is a summary of the 
function that is parameterized with respect to a calling context and is 
used to analyze function calls. As a result we achieve context sensitivity 
at call sites without analyzing the function multiple number of times. 



1 Introduction 



An object is dead at an execution instant if it is not used in future. Ideally, 
garbage collectors should reclaim all objects that are dead at the time of garbage 
collection. However, even state of the art garbage collectors are not able to 
distinguish between reachable objects that are live and reachable objects that 
are dead. Therefore they conservatively approximate the liveness of an object 
by its reachability from a set of locations called the root set (stack locations and 
registers containing program variables). As a consequence, many dead objects 
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are left uncollected. This has been confirmed by empirical studies for Haskell [1] , 
Scheme [2] and Java [3-5]. 

In this paper, we consider a first order functional language without impera- 
tive features and propose a method to release dead objects so that they can be 
collected by the garbage collector. This is done by detecting unused references 
to objects and setting them to null. If all references to the object are nullified, 
then the dead objects may become unreachable and may be claimed by garbage 
collector. We propose three analyses to obtain the information required for nulli- 
fication: liveness analysis, which computes live references at each program point 
(i.e. the references used by the program beyond the program point), sharing 
analysis, which computes alternate ways to access live references and accessibil- 
ity analysis which ensures that the references used by the nullification statement 
itself exist and do not cause a dereferencing exception. An earlier paper [6] out- 
lined the basic method and provided details of the liveness analysis. This paper 
brings the theoretical aspects of the method to completion. 

As our analyses are interprocedural in scope, the effect of function calls on the 
heap must be modeled precisely. Most program analyses are either not scalable 
because they analyze the same function more than once or imprecise because 
they make overly safe worst-case assumptions about the effect of a function 
on the heap. For a better balance between scalability and precision, one can 
compute context independent summaries of the effect of functions on the heap 
and then use this summary at particular calling context of the function [7-9] . We 
do this by using a variable to represent an unknown context of the function being 
analyzed and setting up constraints expressing the effect of the function with 
respect to the variable. The set of constraints is viewed as a set of CFGs and the 
solution of these constraints is a set of finite state machines approximating the 
languages defined by the CFGs. The solution, which is a summary of the function 
parameterized with respect to a calling context, is used to analyze function calls. 

The main contributions of the paper are as follows. We identify the analy- 
sis required to find mailable references at each program point. As part of the 
analyses, we show how context independent summaries of functions can be ob- 
tained by setting up a set of constraints and solving them by viewing them as a 
CFG. Finally we show how the result can be used for safe insertion of nullifying 
statements in the program. 

1.1 Motivation 

Figure 1(a) shows an example program. The label tt of an expression e denotes 
the program point just before the evaluation of e. The heap memory can be 
viewed as a (possibly unconnected) directed acyclic graph called memory graph 1 
during any instant in the execution of the program. The elements of root set 
are the entry points for the memory graph. The nodes in the memory graph 
are the cons cells allocated in the heap. There are three kind of edges in the 
memory graph: (1) Entry edges from an element of the root set to a heap node, 

1 Since the language under consideration (Sec. 2) does not have any imperative fea- 
tures, the memory graph can not have cycles. 



(define (append Istl Ist2) 
(if (null? Istl) 
Ist2 

(cons (car Istl) 

(append (cdr Istl) Ist2)))) 

(let z ^(cons (cons 4 (cons 5 nil)) 
(cons 6 nil)) in 

(let y <— (cons 3 nil) in , , , . 

7r :(let w <— (append y z) in y 1 *J 

7T 6 :(car (car (cdr w)))))) rjj \ n 

(a) Example program. (b) Memory graph at 7Tb. 

Thick edges denote live links. Edges marked X can be nullified at 7Tb. 
Fig. 1. Example Program and its Memory Graph. 




(2) edges from the car field of a heap node to another, and (3) edges from the 
cdr field of a heap node to another. Elements of the basic data types and the 
0-ary constructor nil form the leaf nodes of the graph. All data is assumed to 
be boxed, i.e. stored in heap cells and accessed through references. The edges in 
the graph are also called links. Figure 1(b) shows the memory graph at nt,. 

The edges shown by thick arrows are those which will be dereferenced beyond 
7Tb. These edges are live at wi,. Edges that are not live can be nullified by the 
compiler by inserting suitable statements. These edges are shown with a x in 
the figure. If an object becomes unreachable due to nullification of such edges, it 
can be collected by the garbage collector. Note that an edge need not be nullified 
if nullifying some other edges makes it unreachable from the root set. 

To find out all mailable edges in a memory graph, we need the following 
analyses: 

— For every program point 7r, liveness analysis finds out all the edges in the 
memory graph that can be potentially dereferenced along some path from it 
to exit. For the program in Fig. 1, the edges corresponding to references w, 
(cdr w), (car (cdr w)), (car (car (cdr w))) should be marked as live at 7Tb. 

— Sharing analysis is used to identify all possible ways to access live edges. 
In Fig. 1, the expression (car z) is not directly used beyond 7th. However, 
sharing analysis gives us that z and (cdr w) share a cons cell. Therefore, we 
can not nullify (car z), as the edge is live due to use of (car (cdr w). Using 
sharing analysis, we infer that the complete set of expressions corresponding 
to live edges at tti, is: w, (cdr w), (car (cdr wj), (car (car (cdr w))), 
(car z), (car (car z)). 

— Since our analysis is static, it is possible that not all the cons cells in the 
sequence of links that we dereference to nullify a non-live link have been 
created during a particular execution of the program. This can happen if 
a cons cell in the sequence of links is allocated in one branch of a condi- 
tional expression and not in the other. Accessibility analysis ensures that 
the statement used for nullification does not dereference a cons cell which 
is not allocated. 



V ■ 

d : 



di . . . d rl e p 



program 



(define (f vi . . . v n ) ei) — function definition 



K 
V 

nil 

(car ei) 

(pair? ei) 

(+ ei e 2 ) 

(if ei e 2 e 3 ) 

(let vi <— e 2 in 63) 

(/ei ... e n ) 



(cons ei e 2 ) 
(cdr ei) 
(null?ei) 



— expression 
constant 
variable 
constructors 
selectors 
testers 

generic primitive 
conditional 
let binding 
function application 



Fig. 2. The syntax of our language 



1.2 Organization 

Section 2 describes the language used to explain our analysis along with the 
basic concepts and notations. Liveness analysis is described in Section 3. Sec- 
tion 4 explains the analysis to compute sharing between root variables. Section 5 
describes availability analysis. Section 6 describes the actual process of null in- 
sertion. The related work is given in Section 7. We conclude in Section 8 and 
give the direction for future research. 



2 Concepts and Notations 

The syntax of our language is shown in Fig. 2. The language has call-by-valuc 
semantics. The argument expressions are evaluated from left to right. We assume 
that variables in the program are renamed so that the same name is not defined 
in multiple scopes. The body of the program is the expression denoted by e pgm . 
We write ir : e to associate tt with the program point just before the expression 
e. 

An edge emanating from a car field is labeled while an edge emanating 
from a cdr field is labeled 1. Entry edges do not have any label. There are two 
kinds of traversals associated with an edge: A forward traversal is in the direction 
of the edge, and a backward traversal is in the opposite direction of the edge. For 
an edge with label 1(1 € {0, 1}), a forward traversal over the edge is denoted by 
I, while I denotes a backward traversal over the edge. 

Given a node in a memory graph, a path is a sequence of labels representing 
a traversal over connected edges starting at the node. In general, a path involves 
both forward as well as backward traversals over edges. A forward path involves 
only forward traversals over edges, and a backward path involves only backward 
traversals over edges. Note that starting from a cons cell there can be multiple 
possible edge traversals labeled or 1, but at most one traversal labeled or 1. 
In general, all forward traversals from a node have unique labels while multiple 
backward traversals may share the same label. A bipath consists of a (possibly 
empty) forward path followed by a (possibly empty) backward path. Note that 



forward and backward paths are special cases of bipath. Only bipaths are impor- 
tant to us because liveness, sharing and accessibility can all be described using 
bipaths. We use Greek letters (a, (3, . . .) to denote paths. The concatenation of 
two path segments a and (3 is denoted by af3. The reverse of a path a, denoted 
a, is the path which traverses the edges of a in the opposite order and opposite 
direction. We have: e = e, and oF[a^ — off. The concatenation (cti -a 2 ) of a set 
of paths a \ with a 2 is defined as a set containing concatenation of each element 
in g 1 with each element in er 2 - 

A path can be simplified by repeatedly removing consecutive occurrences of 
backward and forward traversal of the same edge (in general, removing occur- 
rences of aa) . The reduction does not change the semantics of the path in that 
the node reached by the path remains the same even after simplification. Fur- 
ther, since we are interested in bipaths only, paths containing 10 or 01 can be 
ignored. This gives us the following rules of reduction: 



a — > a' denotes the reduction of a to a' in k steps, and — > denotes the 
reflexive and transitive closure of — >. A path which can not be reduced further 
using above rules is said to be in canonical form. Note that a path in canonical 
form is either a bipath or _L. 

Very often we shall be interested in paths that start from a heap cell pointed 
directly by the root set. We call such paths as access paths. Let Loc[e] denote 
the stack location which holds the value of e 2 and Cellfe] denote the heap node 
pointed to by Loc[e]. We use e.a to denote access path which starts in the heap 
at Cell [e] and traverse the path a. If a denotes a set of paths, then e.a is the set 
of access paths rooted at Cell [e] corresponding to a. i.e. e.a = {e.a a G a} We 
use access paths to refer to links in the memory graph. The link referred to by 
an access path is the last edge in a traversal using the access path. 

The syntax of the meta-language used to describe our analysis is very similar 
to the language being analyzed. To distinguish between them, the keywords in 
the meta-language are written in all capitals (LET, IN, IF etc.). 

3 Liveness Analysis 

A link in a memory graph is live at a program point tt if some expression deref- 
erences it beyond tt. An access path is live if the link denoted by it is live. Note 
that an access path can be live in two ways: either it is used directly to access 
the last link, or it shares the live link with some other access path using which 
the link is made live. Liveness analysis discovers access paths through which the 
live link is directly accessed. 



ai01a2 — > -L 



aillct2 ~~ * cti®-2 
ail0«2 — > -L 



«i_Lq2 — > -L 



(1) 



2 For a root variable r, Loc[r] is same as r. For any other expression e, Loc[e] can be 
thought of as the temporary that holds the value of e. 



The liveness environment at n, denoted C w , describes all the live access 
paths at 7r. It is a function from root variables to sets of paths. The result 
of liveness analysis is the annotation of each program point with its liveness 
environment. The liveness of an access path before an expression e depends 
upon its use inside e itself and in the rest of the program through the result of 
e. Therefore we define a transfer function denoted CE to compute the liveness of 
access paths before an expression, given the liveness of result after the expression. 
As expressions may contain applications of primitive operations and functions, 
we also need to propagate liveness across these applications. This is done through 
the summarizing functions CP and CT . While CP is given directly based on the 
semantics of the primitive, £F is inferred from the body of a function. 

3.1 Liveness Transfer Function (C£) 

For an expression ir : e, a set of paths a specifying the liveness of the result of 
evaluating e and the liveness environment C after e, C£(e, a, C) computes the 
liveness environment at n. The liveness environment associated with the exit of 
any function is empty liveness environment £ defined as Vx C®(x) = 0. The 
liveness associated with the result of the program expression e pgm is cr pgm = 
{0, 1}*, i.e. the entire result of the program is needed. For any other function /, 
the liveness associated with the result is: 

Vexitf = l^J {a - | a" is the liveness of the result of (/ e\ ... e„) after the ca 

all calls (/ ei ... e n ) 

The computation of CE is given in Fig. 3. 3 In the expression (if e\ e-i 63), the 
a for ei is {e} because the value of e\ is used to decide the branch, for which only 
Cell[ei] is used (4). For a let, the liveness of v\ from e 2 and beyond is transferred 
to ei (5). The liveness environment before a primitive application is computed 
by using CP to transfer the liveness from the result of the application to each of 
its arguments (6). Similarly, applications of user defined functions use CF(7). 

As the result of liveness analysis is the annotation of every program point 
with its liveness environment, during computation of C£(e,a, C), the program 
point before e is annotated with the computed liveness environment as a side 
effect. We do not show this explicitly to avoid clutter. 

3.2 Summarizing Functions (CP and jCF) 

If a describes the set of paths specifying the liveness of the result of (P e\ . . . e n ) 
after the call, then CPp(a) gives the set of access paths specifying the liveness of 
d at the program point after ei. The summarizing functions for the primitives in 
our language, car, cdr, cons, null?, pair? and +, are shown below. The 0-ary 
constructor nil does not accept any argument and is ignored. 

O&ri?) = to U {0} • a £P c d» = to U {!> • 

G&mal?) = {0} ■ o CP c 2 ons (a) = {1} • a (8) 

^null?( CT ) = {*>> ^pair?( ff ) = W> = M, = {*} 

3 update is a helper function to compute change in environments: 

update(OldEnv, Y, NewVal)(X) = (IF (X == Y) NewVal (OldEnv X)) 



C£(v, a, C) — update(£, v, £(v) U o) 
££((if ei e 2 e 3 ), <r, £) = (LET £' <- ££(e 3 , a, £) IN 
(LET C" <- CS(e 2 ,a, C) IN 
££( ei ,{e},/:'u£"))) 
££((let wi <- ei in e 2 ), cr, £) = (LET £' <- ££(e 2 , cr, C) IN 

££(ei, £'(t;i), update(£', vi, 0))) 
e n ),cr,£) = (LET jCi <— ££(e„, jCPj^(a), C) IN 



££((P ei 

P is a primitive 



(2) 
(3) 



(4) 
(5) 



(LET £ 2 <- ££(e n _i, £i) IN 



(LET «- ££(e 2 ,£P P 2 ( ( 7),/: n _ 2 ) IN 
CE^CPp 1 (a), £„_i)))...) (6) 
££((/ ei...e„),<r,£) = (LET £i <— ££(e„, £Jj n (a) , £) IN 
/ is a user denned function (LET £ 2 <- ££(e„-i, £7y n_1 (cr)i £i) IN 



(LET C n -i «- ££(e 2 ,£P/(cr),£ n _ 2 ) IN 
C£{e u £„_i)))...) (7) 



Fig. 3. Computing ££ 



£Tc ar (cr) includes {0} -u because the link described by a path labeled a from 
Cell [(car e)] can also be described by the path labeled Oa from Cell[e]. Also, as 
the cell corresponding to e is used to find the value of car, we need to add e to 
the live paths of e. Reasoning about (cdr e) is similar. For similar reasons, a path 
a describing the liveness of cons translates to an 0a for its first argument, and 
la for its second argument. Further, as cons does not read its arguments, the 
access paths of the arguments do not contain e. The remaining primitives read 
only the value of the arguments, therefore the set of live path of the arguments 

iS {6}. 

£F plays the same role as CP for user defined functions. Given a function 
defined as (define (/ v\ . . . v n ) e) and a a specifying the set of paths specifying 
the liveness of the result, £F is computed as follows: 

£F/{a) = C£{e, er, 9)( Vi ), l<i<n (9) 

Example 1. To compute the transfer functions for append, we compute £S(e, a, 0) 
in terms of a variable cr. Here e is the body of append. Figure 4 shows the 
values at various program points in append. From the liveness information of the 
parameters Istl and Ist2, we get: 

^append W = W U ^ ' " U {1} ■ ^ a 1 pperid ({l} • a) 

^append(-)=- U ^ap P end({l}-) D 




Fig. 4. Transformation of access paths for body of append 



3.3 Solving Liveness Equations 

We now describe briefly the steps to solve the liveness equations. The reference [6] 
and the Appendix A both contain a detailed example illustrating these steps. 
Further, the equations resulting out of the sharing analysis are also solved in a 
similar manner. 

In general, the equations defining the functions £F will be recursive. To solve 
such equations we start by guessing that the solution for CTf (a) will be of the 
form: IjLlVj-a, where Tj and T>j are sets of strings over the alphabet {0, 1, 0, 1}. 
Then, 

1. We substitute the guessed form of CFf in the equations and equate the a- 
dependent and cr-independent parts of LHS and RHS of each equation. This 
gives us equations for If and Vf which are independent of a. 

2. We interpret the equations as rules of a context free grammar (CFG) with 
If and T>f as non-terminals. The set of terminal symbols of the CFG is 
{0,1,0,1}. 

3. We add more rules to represent the liveness at different program points in 
terms of the above non-terminals. 

4. We approximate the CFG by a set of non deterministic finite automata 
(NFA) and simplify the NFAs so that the paths in canonical form are ac- 
cepted. The algorithm describing this step and its proof of correctness is 
given in Appendix A. 2. The algorithm is a revised version of that given in 
our earlier work [6]. 

4 Sharing Analysis 

Given a memory graph, expressions ei and e-i are involved in sharing if there are 
forward paths from Cell [ei] and Cell [e2] to a common heap cell. In particular we 
are interested in the sharing of the root variables. Let ft- be a heap cell shared 
by root variables x and y. Let the forward access path x.a describe the path 



Expression: 


(let yi «— (car xi) in 
7Ti : . . .) 


(define (/ Wi v 2 ) n 2 : . . .) 
(/ (car x 2 ) x 2 ) 


(let 2/3 <— (cons 23 x 3 ) in 7r 3 : . . .) 


Sharing: 


e 5^(0:1,2/1) 


G 5 T2 (i)i,D2) 


01.10 G 5^3(2/3,2/3); 0,1 e 5,3(2)3, 2/3) 



Fig. 5. Examples of sharing 



from x to h and the forward access path y.fi describe the path from y to h. 
Then, sharing between x and y can be seen as a bipath labeled a(3 from Cel I [rr] 
to Cel I [y] in the memory graph. Fig. 5 shows some ways in which sharing can 
arise. 

The sharing environment at 7r, denoted 5^, describes the sharing between 
root variables in any memory graph that can arise at it. The sharing environment 
is a function from pairs of root variables to sets of bipaths. The result of sharing 
analysis is to annotate each program point with an approximation of its sharing 
environment. 

Since variables take their values from evaluation of expressions (through let 
or argument bindings), it is convenient to define a function denoted S£, which 
computes the sharing between variables and expressions. Further, we also need 
to propagate sharing environments across applications of primitive operations 
and user defined functions. This is done by using the summarizing functions SP 
and ST. For a primitive P, SPp denotes the sharing between the i th argument 
and the result of P. STj 1 is interpreted in a similar manner. Additionally the 
function SS computes the sharing of an expression with itself. 

4.1 Sharing Transfer Function (S£ ) 

The transfer function SS(x, e, S) computes the extent of sharing between the root 
variable x and the result obtained by evaluating e. 4 In our language, the sharing 
between root variables can only be affected either at the let-binding or at the 
entry of a function. The computation of SS begins at function definitions. The 
sharing environment before the program expression e pgm is the empty sharing 
environment S® defined as Wx,y S®(x,x ) = {e},5 (x,?y) = 0. For any other 
function /, defined as (define (/ v\ . . . v n ) e), the initial sharing environment 
Sentry; is as shown in Fig. 6. 

The computation of S£(x,e,S) is given in Fig. 7. Equations (10) and (11) 
are self-explanatory. In an if expression, sharing can be due to execution of 
either branch. The sharing between x and e\ is computed to propagate the 
sharing environment inside e\; it does not affect the sharing between x and the 
if expression. For a let expression, sharing environment S' at €2 captures the 
sharing between x and v\ (13). Finally, the sharing between x and the result of 
application of a primitive P is obtained by composing the sharing between x and 
ei with the sharing between the and the result (14). User defined functions 

4 The function can easily be extended to a set of variables so that only a single pass 
over the expression is required. 



Sentry f (v l ,V l ) = {e} U [J SS(ei,S n ) 

7r:(/ e 1 ... e„) 

Gentry f (vi,Vj) = [J £SS(e l , ej, S n , SVars(7r)) 

tt:(/ ex ... e„) 

where 1 < i, j < n, i / j, SVars(7r) = set of root variables in scope at n 
££S(e, e , S, Vars) = {a/3 | a G S£(x,e,S),f3 € S£(x,e ,S),x € Vars} 
Fig. 6. Sharing at the entry of a function 



S£(x,k,S) = 
S£(x,v,S) — S(x,v) 
■SE(z,(ifei e 2 e 3 ),5) = (LET S' <- S£(x,e u S) IN 
>S£(a;, e 2 , 5) U S£(x, e 3 ,S)) 



(10) 
(11) 

{<S' is ignored} 

(12) 



S£(x, (let vi <- ei in e 2 ),S) = (LET 5' <- update(«S, (vi, vi), {e} U <SS(ei, S)) IN 

(LET 5" <- update(S', (x, vi),S£(x, ei, <S)) IN 

ca, 5"))) (13) 
|J 5£(a:, ei ,S)-<SPp l (14) 



«S£(a:, (P ei ... e„),<S) = 
P is a primitive i 

S£(x, (/ei ... e„),<S) = [J 5£(a;, e<, 5) ■ <S7y ! 
/ is a user defined function i<i<n 

Fig. 7. Computing S£ 



(15) 



(15) are treated similarly. Note that only let expression modifies the sharing 
environment. During computation of S£(x, e, S) the program point before e is 
annotated with S. However, as in ££, we do not show this explicitly. 



4.2 Summarizing Functions (SP and <XF) 

SP specifies the extent of sharing between the formal arguments of a primitive 
and its return value. The sharing between i th argument and the result is denoted 
by SPp. For a primitive application (P e\ . . . e n ): 

a(3 € SPp => there is a bipath a/3 from Loc[ei] to Loc[(P ei . . . e n )] 

The functions SPp, of a primitive are computed from its semantics: 

<SPcar = {0} SP c d r = W SPcons = W «SP c 2 on s = {1} , 1R v 
^null? = 5P pair? = ^+ = ^+ = 

ST 7 specifies the extent of sharing between the formal arguments of a function 
and its return value. The sharing between i th argument and the result is denoted 
by SPp. For a function defined as (define (/ v\ ... v n ) e), SJy is computed as 



SS(k,S) = {e} 
SS(v,S) = S(v,v) 



(18) 
(19) 

«SS((if ei e 2 e 3 ),«S) = <SS(e 2 , 5) U SS(e 3 , S) (20) 
<SS((let V! <- TTnei ine 2 ),<S) = (LET 5 <- update(S, (vj, vi), SS(e u S)) IN 

(LET5i <- update(5i, (xi, vi), 5£(xi, ei, 5)) IN 



SVars(7n) = {xi, . . . , £„} 



SS(tv: (Pei ... e„),5) 
P is a primitive 



<SS(7r: (/ ei ... e„),<S) 
/ is a user defined function 



(LET«S„ <- update(<S„_i,(x n ,v 1 ),<S£:(x n ,ei,<S)) IN 
5S(e 2 ,5„))...)) (21) 
|J SP£- dj£SS(e,, ej ,«S,SVars(7r))) ■ SPj 



l<i,i<r, 



U (J <SP P ! -SS(ei,5) ->SPp ! (22) 

l<i<n 

(J SFf ■ ({j££S(ei, ej ,S, SVars(Tr))) ■ ST/ 

\<i,j<n vr 

i¥=3 

U |J ^ I -«SS(e i ,<S)-<S^ i (23) 



Fig. 8. Computing <SS 



follows: 



S£(v i ,e 7 S f '), l<i<n 



(17) 



4.3 Sharing with Self (SS) 

Because of the sharing in the subexpressions, the result of an expression may 
share a cons cell along two different paths. We call it self sharing, and use the 
function SS to capture it. The computation of SS is shown in Fig. 8. 



4.4 Computing Aliases of Access Paths 

We say that two access paths are aliased at a program point if they share the 
same cons cell in the heap at that point. We distinguish between two kinds of 
aliases: two access paths are ?mfc-aliases if they share the last edge in the path, 
otherwise they are node-aliases. 

The result of sharing analysis can be used to compute all aliases of a given 
access path at a given point. Let n be a program point, and let S v be the sharing 
environment at n. Further, let x.a be an access path under consideration, where 
a is a forward path. To find out the aliases of x.a rooted at y, we proceed 
as follows. Consider the set S 7T (y,x) which contains the bipaths from Cell [y] 
to Cell[x]. For (3 £ S n (y,x), if Pa reduces to a forward path then y.(3a is a 
forward access path which reaches the same cons cell as that reached by x.a 
implying that y./3a is an alias of x.a. Because we do not have the bipaths in 



Spi explicitly listed, we have to compute CFGs describing the bipaths. This is 
same as described for liveness (App. A, [6]). We also compute the trivial CFG 
describing the string a. The concatenation of CFG describing S v (y,x) with 
CFG describing the string a gives a CFG, which after conversion to NFA and 
simplification gives the regular grammar describing the aliases of x.a rooted at 

y- 

The link alias of a root variable x is x itself. To get the link-aliases of x.aO, 
we compute aliases of x.a as described above, and extend it by 0. Similarly we 
can compute link-aliases for x.al. 

5 Accessibility Analysis 

To nullify a link I at a program point tt, we have to traverse an access path from 
some root variable, say v, to the source cell of I. However, it is possible that some 
cons cell c in the access path from v to I is created along one execution path to 
tt but not along another. Since the nullification of I at tt requires the cell c to be 
dereferenced, a run time exception may occur if the execution path taken is the 
one along which c is not created. To avoid this, we need to make sure that the 
access path used for nullification is such that all the intermediate cells in it are 
definitely created. 

Example 2. Consider the following program fragment: 

(let x <— (if (y < 5) (cons 2 z) nil) in 7r:(if (y > 5) tt\ : w tt 2 :(cdr x j) 
Observe that the program does not raise a dereferencing exception. Assume 
that the link x.O is not live at tt. This information is not sufficient to nullify x.Q 
safely at tt because it does not guarantee that variable x points to a cons cell 
at tt. Similarly, knowing that x.O is not live at tti or tt 2 does not enable us to 
nullify x.O at those points. However, since (cdr x) dereferences x, we can infer 
that x can be dereferenced at tt 2 . Thus, we can safely nullify x.O at tt 2 . □ 

Assuming that the program cannot generate a dereferencing exception, it is 
possible to infer the set of access paths that can be dereferenced without causing 
exception. We call such paths accessible. There are two ways in which the set of 
accessible paths can be inferred at tt. We can discover access paths in which all 
the cons cells are either created or dereferenced along all program paths from 
the program entry to tt. We call these paths as available paths at tt. Secondly, we 
can discover access paths in which all the cons cells are dereferenced along all 
program paths from tt to the program exit. We call these paths as anticipable. 

In this paper we describe availability analysis only. The result of availability 
analysis is the availability environment, denoted A, corresponding to each pro- 
gram point. It is a function from root variables to the corresponding available 
access paths. We next describe how the availability environment is computed. 

5.1 Availability Transfer Function (A£) 

In general, an expression has to dereference the structures corresponding to its 
subexpressions. Therefore, for execution to proceed normally, these structures 



must exist. We call this requirement as the demand on a subexpression. We use a 
set of paths to describe the demand. The demand from the enclosing expression 
is modified by an expression and passed to its subexpressions. 

Example 3. car and cdr require that their arguments are non null. Thus, for 
expression (car 7Ti : (cdr 7r 2 : x)), the demand at tti is {e} due to the car 
application. The demand at 7r 2 is {e, 1}, where e is due to cdr, and 1 is because 
of the demand of car on (cdr x) which is modified and passed to x. □ 

The way availability information is generated and propagated is as follows. 
Consider an expression (car (cdr x)). Assume that the availability environment 
before this expression indicates that no access path rooted at x is available. When 
we reach the subexpression x, the chain of selectors (car (cdr . . . generates 
the demand {e, 1} on x. We thus update the availability environment of x to 
include x.{e, 1}. This availability is propagated upwards and used to conclude 
that the availability of (cdr x) is e. Thus availability analysis involves a inward 
propagation of demand followed by an outward propagation of availability. 

Given an expression e, the set of access paths o describing the demand on 
the result of e and the availability environment A at the program point before e, 
we compute the availability of e and the availability environment after e using 
the transfer function AS. This is described in Fig. 9. Availability analysis is an 
all paths problem. We get constraints involving intersection operation for sets 
describing availability. As intersection operation can not be mapped directly 
to CFGs, we need to get an approximate (but safe) solution. This is achieved 
by an intraprocedural analysis in which we neither propagate the demand from 
function application to its arguments, nor propagate the availability of arguments 
to the function application (29). A straightforward unfolding of AS will give us 
the availability environment at different program points. 

5.2 Inward Propagation of Demand {AP) 

If a describes the set of paths specifying the demand on the result of evaluat- 
ing the primitive application (P ei . . .e n ) then APp(<r) gives the set of paths 
representing the demand on e^. 

A&ri?) = U) U {0} • a = to U W ' a 

^Pcons(^) = {0} • a AP c l ns (a) = {1} ■ ° (30) 

^null?^) = > ■^pair?( <7 )= ' = > ■ AP +( a ) = 

5.3 Outward Propagation of Availability (ABP) 

If a describes the availability of i th argument of (P e\ . . . e„), then ABPp(<r) gives 
the availability of (P e\ . . . e n ). For the primitives in our language: 

JBP&rV) = {0} • o -^drW = {1} • " 

^PconsW = Hu{0}-a ^cons W = H U {1} • a (31) 



J£(n,a,A) = ({e},A) (24) 
A€(v, a, A) = (LET A' <- update^, v, A(y) U cr) IN 

(A'(v),A')) (25) 
^£((ifei e 2 e 3 ),cr,„4) = (LET (a u Ai) «- A£{e 1 ,{e},A) IN 
(LET (a 2 ,A 2 ) <- ^(e 2 ,<7,A) IN 
(LET (<7 3 , -As) <- A€(e 3 ,<r,Ai) IN 
(aU(a 2 na 3 ),^')))) (26) 
■A 2 (w) nA 3 {v) 

(LET (cr',.4') <-.A£(ei,0,.A) IN 
A£(e 2 ,cT, update^', vi,</))) ( 27 ) 
(LET (<ti,.Ai) ^^(ei,^ 1 ^),^) IN (28) 
(LET (a 2 ,A 2 ) <- ^(e 2 ,^p 2 (cr),^i) IN 



where .A'(v) 
,4£((let wi <— ei in e 2 ), cr, .4) 

AS((Pei ... e n ),a,A) 
P is a primitive 



(LET K^^^^fe^^H^n-i) IN 
(a U \J ABPMoi),A n ))...)) 



A£((f ei ...e n ),a, A) 
f is a user defined function 



(LET (ffi.^i) 
(LET (ff 2 , AO 



^(ei,0,A IN 
-AS(e 2 ,®,Ai) IN 



(29) 



(LET (<7„,A0 A£(e n ,®,A n -i) IN 

(ff.A,))...)) 

Fig. 9. Computing AS 



6 Null Insertion 

We need to consider the following issues for null insertion: 

— Safety: No live edge should be nullified. Further, the expression used to 
nullify an edge should not dereference a null reference. 

- Profitability: An edge should be nullified as early as possible. Multiple nul- 
lification of same edge, through the same expression or through its aliases, 
should be avoided. 

Safety, can be achieved by the following: 

The proper prefixes of the access path used for nullification should be avail- 
able. Thus, the candidate access paths at a given program point can be 
obtained by extending available access paths with a and a 1. Additionally, 
all root variables are also candidates for null insertion. The liveness of only 
these paths need to be checked for null insertion. Thus, 

Candidates(Tr) = (J v.({e} U {aO, al | a G A v {v)}) 

i'GSVars(-Tr) 

To make sure that the link described by a candidate path v. a is not live, we 
have to compute link aliases of v. a and ensure that none of them is live at 

7T. 



1. 



2. 



Our analyses annotate liveness, sharing and availability environments at the 
program points before the expressions. Therefore, we nullify dead links at these 
program points only. The analyses can easily be extended to compute the en- 
vironments at the program points after the expressions, so that links can be 
nullified at these points. 

To address the profitability issue, we visit the program points in the order 
of execution (reverse depth-first order of the expression tree) to nullify links. 
We mark the access paths which are already used for nullification, and do not 
nullify them again. However, redundant null insertions are still possible because 
the same link may be nullified more than once through aliased access paths. In 
general it is not possible to eliminate redundant null insertions. However, we can 
reduce them by computing must-aliases that hold on all paths, and marking all 
must-link-aliases of the access path used for nullification. 

A given nullifiable access path can be translated into equivalent expression 
for nullification of the link it represents. We need three primitives in our mcta 
language to achieve the effect of nullification. These are: SET! to nullify root 
variable, SET-CAR! to nullify car references, and SET-CDR! to nullify cdr 
references. The expression for nullification from access path is obtained using 
the function Nullify which is inserted at appropriate program points: 

(SET! v nil) a = e 
LinkNullify(a, v) a^e 

. . (SET-CDR! e nil) a = e 

LinkNullify(la,e) = < . . ... , , , \, , 
v ' I LinkNulhfy(a, (cdr e)) a e 

,. ... „., . | (SET-CAR! e nil) a = e 

LinkNullify(Oa,e) = <^ v . , , \, . 

JK ' y LmkNullify(a, (car e)) a/e 

7 Related Work 



Nullify(u.a) 



Existing literature regarding improving memory usage can be categorized as 
follows: 

Compile time reuse. The method by Barth [10] detects memory cells with zero 
reference count and reallocates them for further use in the program. Jones and 
Le Metayer [11] describe a sharing analysis based garbage collection for reusing 
of cells which collects a cell provided expressions using it do not need it for their 
evaluation. 

Explicit reclamation. Shaham ct. al. [12] use an automaton called heap safety 
automaton to model safety of inserting a free statement at a given program point. 
The analysis is based on shape analysis [13] and is very precise. However it is 
very inefficient. Free-Me [14] combines a lightweight pointer analysis with liveness 
information that detects when short-lived objects die and insert statements to 
free such objects. The analysis is simpler and cheaper as the scope is limited. 
The analysis described by Inoue et. al. [15] detects the scope (function) out of 
which a cell becomes unreachable, and explicitly claims the cell whenever the 
execution goes out of that scope. Like our method, the result of their analysis is 
also represented using CFGs. The main difference between their work and ours 



is that we detect and nullify dead links at any point of the program, while they 
detect and collect objects that are unreachable at function boundaries. 
Making dead objects unreachable. The most popular approach to make dead ob- 
jects unreachable is to identify live variables and reduce the root set to only these 
variables [16]. The drawback of this approach is that all heap objects reachable 
from the live root variables are considered live, even if some of them remain 
unused. Escape analysis [17, 18] based approaches discover objects escaping a 
procedure, i.e. objects whose lifetimes outlive the procedure that created them. 
All non-escaping objects are allocated on stack, whereby they become unreach- 
able whenever the creating procedure exits. Region based garbage collection [19] 
uses region inference [20] to identify regions that are allocated storage for objects. 
Memory blocks are always allocated in a particular region and are deallocated 
at the end of that region's lifetime. Escape analysis and region inference detect 
garbage only at the boundaries of certain predefined areas of the program. In 
our previous work [21], we have used bounded abstractions of access paths called 
access graphs to describe the liveness of memory links in imperative programs 
and have used this information to nullify dead links. This paper is completion 
of our earlier work [6], where we used liveness to introduce the ideas presented 
in this paper. 

8 Conclusions and Future Work 

In this paper we have proposed a method to nullify links in heap memory to 
improve garbage collection. The method consists of a set of analyses to discover 
dead references at every program point followed by the actual insertion of null 
statements. We claim that the analyses are both scalable and precise — scalable 
because we obtain a context dependent summary of each function call, and 
precise because the summaries are used in a context- and flow-sensitive analysis 
of each function call. The method is very similar to the functional method of 
intcrproccdural analysis. However we have not found any published work which 
describes the functional method for non bit-vector problems. 

This work can be extended in many directions. We can extend the language 
to include higher-order functions. The scope of the method can be extended 
to include dead-code elimination. If a reference to the value of (cons ei e?) 
is never used, the expression need not be evaluated at all. Our method, in its 
present form, would first evaluate the expression and then nullify the reference 
to it. The safety of nullification has to be proven. Finally, the method has to be 
implemented to demonstrate its effectiveness. 
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A Solving Liveness Equations 



In general, the equations defining the functions CJ- will be recursive. To solve 
such equations, we start by guessing that the solution will be of the form: 

£F/(<t) =I/UD/ -a, 

where and are sets of strings over the alphabet {0,1,0,1}. The in- 
tuition behind this form of solution is as follows: The function / can use its 
argument locally and/or copy a part of it to the return value being computed. 

is the set of live paths of i th argument due to local use in /. T>j is a sort of 
selector that selects the live paths corresponding to the i th argument of / from 
a, the liveness paths of the return value. 

If we substitute the guessed form of £Jy l in the equations describing it and 
equate the terms containing a and the terms without a, we get the equations 
for If and T>j. This is illustrated in the following example. 

Example 4- Consider the equation for £^ 3 pp enc |( <T ) from Example 1: 

^append^) = H U ^ " CT U W ' ^append^ ' CT ) 

Decomposing both sides of the equation, and rearranging gives: 

append append L ' _ L 1 append 

u{oo}.*u{i}.vi ppend -{i}.* 

Separating the parts that are a dependent and the parts that are a independent, 
and equating them separately, we get: 

append L '_ L ' append 
Append - = {06} -ay {1} • ■ {l}a 

= ({00}U{l}.^ ppend .{l}).a 

As the equations hold for any general a, we simplify them to: 

1 1 a = {e}U\l}-l i . 
append 1 J _ 1 ' append 

V 1 , = {00}U{1}-P 1 ,-{1} 
append 1 ' L ' append L ' 

Similarly, from the equation describing £7^pp enc j (c), w e get: 

1 2 =1 2 
append append 

V 2 , = {e}UV 2 ,-{1} 
append 1 1 append 1 J 

These equations describe the transfer functions for append. □ 

The values of 1 and V are sets of strings over the alphabet {0,1,0,1}. 
We are interested in least solutions to the equations describing J and V. We 
use context free grammars (CFG) to describe these solutions. The set of termi- 
nal symbols of the CFG is {0,1,0,1}. Non-terminals and associated rules are 
constructed as illustrated in Examples 5 and 6. 

Example 5. Consider the following constraint from Example 4: 
Append = W U W '^append 



We add non- terminal (^p pen( j> and the productions with right hand sides directly 
derived from the constraints: 

CI 1 ,)^e|l(J 1 ,) 
v append' 1 x append' 

The productions generated from other constraints of Example 4 are: 

CD 1 ,)- > 00|l(O 1 ,)1 
v append' 1 x append' 

CI 2 ) —> CI 2 ) 
x append' x append' 

CD 2 ,)^e\CD 2 ,)1 
v append' 1 x append' 

These productions describe the transfer functions of append. □ 

The liveness environment at each program point can be represented as a CFG 
with a start symbol for every variable. To do so, the analysis starts with {N pgm ), 
the non-terminal describing the liveness of the result of the program, <r pgm . The 
productions for (iVpgm) are: 

(N pgm ) -> e | 0{iV pgm > | l{iV pgm > 

Example 6. Let denote the non-terminal corresponding to the liveness asso- 
ciated with a variable v at program point n. For the program of Fig. 1: 
<iV-> - e | 1 | 10 | 100(iV pgm > 

( N V "> Append) I ^append) I ^append) 1 I ^append) 10 

I ^append) 10 0^-) 
^*«^ ~~ * ^append^ I ^append^ I ^append^ I ^append^^ 

^ppend) 100 ^) ' D 

It is possible that different paths, which arc not in canonical form, may 
reduce to the same canonical path and hence encode the same information. We 
arc interested in the information encoded by the paths, and therefore want to 
check memberships of canonical paths in CFGs. However, the paths described 
by the CFGs resulting out of our analysis are not in canonical form. It is not 
obvious how to check the membership of canonical paths directly in such CFGs. 
To solve this problem, we need equivalent CFGs such that if a belongs to an 
original CFG and a ft, where (3 is in canonical form, then f3 belongs to 
the corresponding new CFG. Directly converting the reduction rules (1) into 
productions and adding it to the grammar results in unrestricted grammar [22]. 
To simplify the problem, we approximate original CFGs by non-deterministic 
finite automata (NFAs) and convert them to equivalent NFAs which can be used 
to check the membership of canonical paths. 



A.l Approximating CFGs using NFAs 

The conversion of a CFG G to an approximate NFA N should be safe in that 
the language accepted by N should be a superset of the language accepted by 
G. We use the algorithm described by Mohri and Nederhof [23]. The algorithm 
transforms a CFG to a restricted form called strongly regular CFG which can be 
converted easily to a finite automaton. 



Example 7. We show the approximate NFAs for each of the non-terminals in 
Example 5 and Example 6. 



append' 




j- 1 y start/ 
append'' 



starts 



Note that there is no automaton for (1 

.l—j)- this is because the least solution 
v append' 

of the equation {^ a p penc j) (^ 2 p penc |) i s 0- Also, the language accepted by the 

automaton for T) 1 , is approximate as it does not ensure that there is an 
append ^ 

equal number of 1 and 1 in the strings generated by rules for (Depend)' ^ 



A. 2 Conversion of NFAs to Accept Canonical Paths 

Algorithm 1 converts an NFA with transitions on symbols and 1 to an equiv- 
alent NFA without any transitions on these symbols. The algorithm repeatedly 
introduces e edges to bypass a pair of consecutive edges labeled 00 or 11. The 
process is continued till a fixed point is reached. When the fixed point is reached, 
the resulting NFA contains the canonical paths corresponding to all the paths 
in the original NFA. The paths not in canonical form are deleted by removing 
edges labeled and 1. Note that by our reduction rules if a is accepted by N 
and a — > _L, then _L should be accepted by N, However, N returned by our 
algorithm does not accept _L. This is not a problem because the paths which are 
tested for membership against N do not include _L as well. 

Example 8. We show the elimination of and 1 for the automata for (N% a ) 
and {N%J. The automaton for (iV™) remains unchanged as it does not contain 
transitions on and 1. The automata at the termination of the loop in the 
algorithm are: 

o k o 





Eliminating the edges labeled and 1, and removing the dead states gives: 



Algorithm 1 Simplifying NFA 



Input: An NFA N with underlying alphabet {0, 1, 0, 1} 

Output: An NFA N with underlying alphabet {0, 1} accepting the equivalent set of 

paths 

Steps: 

i <- 

No «- Equivalent NFA of N without e-moves [22] 
repeat 

N; +1 «- N, 

for all states q in N» such that q has an incoming edge from q' with label and 
outgoing edge to q" with label do 

add an edge in Nj +1 from q' to q" with label e. {bypass 00 using e} 
end for 

for all states q in N; such that q has an incoming edge from q' with label 1 and 
outgoing edge to q" with label 1 do 

add an edge in N^ +1 from q' to q" with label e. {bypass 11 using e} 
end for 

N i+ i <— Equivalent NFA of N^ +1 without e-moves 
i <- z + 1 
until (N, = Ni_i) 

delete all edges with label or 1 in N. 



The language accepted by these automata represent the live access paths 
corresponding to y and z at 7r a . □ 

We now give the proofs of the termination and correctness of our algorithm. 



Termination Termination of the algorithm follows from the fact that every 
iteration of do-while loop adds new edges to the NFA, while old edges are not 
deleted. Since no new states are added to NFA, only a fixed number of edges 
can be added before we reach a fix point. 



Correctness The sequence of obtaining N from N can be viewed as follows, 
with N m denoting the NFA at the termination of while loop: 

— deletion addition , deletion deletion 
N *■ N ► • • • N Nj • • • ► N m 

of e-edges of e-edges of e-edges of e-edges 

deletion of 

N m _— N 

0, 1 edges 



Then, the languages accepted by these NFAs have the following relation: 



L(N) = L(N ) C ■ • ■ C L(NJ) = L(Ni) C • • • = L(N m ) 



L(N) C L(N m ) 

We first prove that the addition of e-cdges in the while loop does not add 
any new information, i.e. any path accepted by the NFA after the addition of 
e-edges is a reduced version of some path existing in the NFA before the addition 
of e-edges. 

Lemma 1. for i > 0, if a G £(Nj) then there exists a' G L(N i _ i ) such that 

i * 
a — > a. 

Proof. As L(Ni) = L(N<), we have a G L(N^). Only difference between and 
Nj_i is that contains some extra e-edges. Thus, any e-edge free path in 
is also in Nj_i. Consider a path p in N- that accepts a. Assume the number of 
e edges in p is fc. The proof is by induction on fc. 

(BASE) k = 0, i.e. p does not contains any e-edge: As the path p is e-edge free, 
it must be present in N,_i. Thus, Nj_i also accepts a. a — > a. 
(HYPOTHESIS) For any a G £(Nj) with accepting path p having less than k 
e-edges there exists a' G L(Nj_i) such that a' — > a. 

(INDUCTION) p contains k e-edges ei, . . . , e^: Assume e\ connects states q' and 
q" in N-. By construction, there exists a state q in such that there is an edge 
e[ from q 1 to q with label 0(1) and an edge e'[ from q to q" with label 0(1) in 
N^. Replace e\ by e\e'[ in p to get a new path p" in N^. Let a" be the path 

accepted by p". Clearly, a" — > a. Since p" has fc — 1 e-edges, a" is accepted by 
along a path (p") that has less than k e-edges. By induction hypothesis, we 

have a' G L(Nj_i) such that a' A a". This along with a" -i a gives a' A a. 

Corollary 1. /or eac/i a G L(N m ), i/iere exists a' G L(N) suc/i £/iaf a' A a. 

Proof. The proof is by induction on to, and using Lemma 1. 

The following lemma shows that the the language accepted by N m is closed 
with respect to reduction of paths. 

Lemma 2. For a G L(N m ), if a — > a' and a' =/= _L, then a' G L(N m ). 

Proof. Assume a — ► a'. The Proof is by induction on fc, number of steps in 
reduction. 

(BASE) case fc = is trivial as a — ► a. 

(HYPOTHESIS) Assume that for a G L(N m ), if a ^ a', then a' G L(N m ). 

(INDUCTION) a G L(N m ), a a'. There exists a" such that: a ^ a" -i a'. 
By induction hypothesis, we have a" G L(N m ). 

For a" — > a' to hold we must have a" = a\QQa 2 and a' = a\a 2 , or a" = 
ailla2 and a' = ai«2- Consider the case when a" — cuiOOa^- Any path in N m 
accepting a" must have the following structure (The states shown separately 
may not necessarily be different): 




As N m is the fixed point NFA for the iteration process described in the algorithm, 
adding an e-edge between states q' and q" will not change the language accepted 
by N m . But, the path accepted after adding an e-edge is a\a 2 = a'. Thus, 
a' G L(N m ). The case when a" — ailla 2 is identical. 

Corollary 2. For a G L(N), if a A a' and a' ^ T, then a' G L(N m ). 

Proof. L(N) C L(N m ) => a e L(N m ). The proof follows from Lemma 2. 

The following theorem asserts the equivalence of N and N with respect to 
the equivalence of paths, i.e. every path in N has an equivalent canonical path 
in N, and for every canonical path in N, there exists an equivalent path in N. 

Theorem 1. Let N be an NFA with underlying alphabet {0,1,0,1}. Let NFA 

N be the NFA with underlying alphabet {0, 1} returned by the algorithm. Then, 

1. if a G L(N), (3 is a canonical path such that a A (3 and [3 ^ _L ; then 
(3 G L(N). 

2. if (3 G i(N) then there exists a path a G L(N) such that a — ► (3. 
Proof. 

1. From Corollary 2: 

a G L(N), a A (3 and (3 ^ _L => (3 G L(N m ). As f3 is in canonical form, the 
path accepting f3 in N m consists of edges labeled and 1 only. The same 
path exists in N. Thus N also accepts [3 => (3 G L(N). 

2. L(N) C L(N m ) => 13 G L(N m ). Using Corollary 1, there exists a G L(N) 
such that a — > /3. 



